1. Technical Field
The present invention relates to data processing and, in particular, to software state machines. Still more particularly, the present invention provides a method, apparatus, and program for a programming framework for creating, using, and re-using software state machines.
2. Description of Related Art
State machines, also referred to as “finite state machines,” are computing devices designed with the operational states required to solve a specific problem. The circuits are minimized and specialized for the application. There are countless special-purpose devices built as state machines.
A hardware state machine typically receives one or more inputs, determines from those inputs whether the current state changes, and takes an action when a state transition occurs. For example, an elevator may be in a state of “stopped” and recognize that a floor button is pressed. In response, the elevator state machine may then transition to a “moving” state.
With reference to FIG. 1, a block diagram of a typical hardware state machine is shown. The hardware state machine receives inputs through inputs latch 102. The state calculator 110 determines the current state based on the inputs. The state machine may provide the current state 112. The state machine may also provide outputs through output latch 114 or take an action through control circuits 116. Therefore, in the above example, if the elevator state machine transitions from “stopped” to “moving,” the state machine may activate a control circuit to close the elevator doors.
State transitions in a hardware state machine are typically synchronized with a clock, such as clock 120 in FIG. 1. The state calculator may simply look up the current state and the inputs in a table. Thus, state calculator 110 may simply be a lookup table in a memory.
Software may also operate as a state machine. For example, a software media player may be in a “stopped,” “paused,” or “playing” state. The software media player, in this example, may monitor graphical buttons on a media player interface and change state in response to activation of those buttons.
With reference now to FIG. 2, a block diagram of a typical software state machine is shown. The software equivalent of latching inputs is to collect them by a means such as reading them into input variables. The software inputs are shown as conditions 202. The state calculator 210 determines whether to make a state change based on the current state and the conditions. The state calculator may comprise a sequence of conditional statements, such as “if-then” statements, or it may use other means such as a switch statement or a dispatching table.
The software equivalent of control circuits is the invocation of actions 216, which may be software instructions, programs, methods, etc. The software equivalent of synchronizing to a clock may be to monitor events that have been collected into an event FIFO (first-in, first-out). Thus, a software state machine may include event triggers 220 that “listen to” events and record them into FIFO 222. Typically, the event triggers simply monitor for a change in conditions 202.
The design of software state machines may be simple for some applications. The designer may simply create a table of states, actions and conditions. The programmer must then create software instructions for each potential state transition. This is no easy task, particularly for more complicated applications. Also, once a software state machine is created, it may be difficult to make changes. For example, if there is an error in one of the state transitions, it would be very difficult to locate and modify the instructions that pertain to that particular state transition in the code.
Furthermore, once software state machines are created, it is difficult for one software state machine to interact with another software state machine. Each state machine may be programmed in a different language using different conventions. Thus, it may be impossible, or at least very difficult, to receive the state of a software state machine once it is coded. It is important to be able to reuse state machines in the designs of new state machines. Unless the design of the state machine provides a means that the outputs of one state machine can be used as the inputs to other state machines, and unless that means follows good component-oriented and object-oriented principles, combining the state machines can be very difficult.
Therefore, it would be advantageous to provide an improved programming framework for creating, using, and combining software state machines.